Note that in the disclosure that follows, that DOCSIS®, eDOCSIS™, PacketCable™, CableHome®, CableOffice™, OpenCable™, CableCARD™, DCAS™, and CableLabs® are trademarks of Cable Television Laboratories, Inc.
For decades, cable companies, network programmers, consumer electronics companies and computer software makers have sought to deploy interactive TV services on a large scale. Many of their efforts have borne fruit with new interactive games, news and local information, sports statistics, advertising, shopping, program guides, music, polling, banking and other television enhancements.
The development of interactive services is a costly undertaking. One obstacle to mass market deployment of these services was the prospect of having to write and maintain applications for platforms of multiple vendors. What was needed was a set of standards to assure that an interactive application that would run on one particular make of set-top box, middleware platform or digital device would also run on products of other manufacturers.
The OpenCable Application Platform, or OCAP, provides an operating system layer designed for interaction with consumer electronics connected to a cable television network. More specifically, OCAP defines a middleware layer that enables interactive television application developers to produce a single product that is compatible with any cable television system in North America that implements OCAP, independent of the manufacturer or operating system of the set-top device.
One feature explicitly outlined in OpenCable Application Platform Specification (OCAP) 1.0 Profile (OC-SP-OCAP1.0-116-050803) (herein, the OCAP Specification; the OCAP Specification is incorporated herein for all purposes) is the Application Information Table, or AIT. The AIT is developed at a head-end device, or distributor of streaming data, typically by a programmer producing the applications or an administrator overseeing the distribution of the applications. The AIT includes information for instructing a receiving set-top device as to the applications that are currently available and associated with the current broadcast stream and how to start them, as well as additional information for both the set-top device and the user of the device. Common examples of applications include interactive games, sports statistics, home shopping and banking. Related to the AIT is the Extended Application Information Table, or the XAIT. This table provides information about “unbound” applications which are not associated with the currently presenting broadcast service and may be run at any time. Common examples include an interactive program guide and customer care applications.
FIG. 1 illustrates an OCAP host stack as known in the art. The OCAP application layer 108 comprises monitor application 102, electronic program guide application 104, wrappers for native applications 110, and other applications 106.
The OCAP middleware layer 112 comprises software that operates between OCAP applications and the operating system 140 of an OCAP host device (such as a set top box, a DVR, a cable card). The job of the middleware layer 112 is to translate what lies at the root level for what sits above it—so that, say, an interactive trigger from a programmer does not need to know what version of OS is being used in a particular OCAP host device. The software modules (not illustrated) of middleware level 112 run on a JAVA execution engine 130. Native applications 160 may also be executed by execution engine 130 provided a JAVA wrapper 110 is provided.
For example, the middleware helps an interactive game to run on a cable set-top box, or an “interactive digital cable ready” device, and interact with a cable system. When OCAP-compliant middleware is in those devices (i.e., OCAP host devices), then developers can be reasonably assured that their OCAP-based programs will run on those devices. In this way, OCAP creates a means to establish a standardized, international platform to launch all sorts of interactive services on all sorts of digital devices.
Before an OCAP host device can actually run an application, several things have to happen. First of all, the OCAP host device has to “know” that the application actually exists. Second, it has to “know” that the user is allowed to run it at the current time. Finally, it has to be able to access everything that it actually needs to run the application, such as class files and data files or assets.
Every application is associated with a service (either an actual service or an abstract service). The lifecycle of an application is intimately connected with the service to which it is associated. For example, a video receiver that is tuned to a channel is using the “services” associated with that programming. When the viewer changes channel, any applications that are associated with the previous channel may be terminated and new applications will be downloaded and operated. Thus, OCAP restricts the applications that can run at any one time to those that the broadcaster has decided are relevant to what the viewer is currently watching.
Although OCAP applications are usually associated with a broadcast service, it is possible to download OCAP applications and store them in the receiver for use later. Even these applications are part of a service, albeit an abstract service that is only used for grouping applications.
A service in digital TV terminology means a single collection of service information, video and audio streams that can be presented together as a coherent entity. One TV channel (e.g. CNN or BBC) is a service. Services may have more than one audio or video stream, and the receiver will choose which ones to play.
Typically, all of the information about an application (even one that will be downloaded and stored for later use) will be carried within the data stream that carries the audio and video for the parent service. This information consists of two parts:                1. The files that make up the application, its assets, and its data are carried in a DSM-CC object carousel. This acts as a broadcast file system from which the receiver can read any files that it needs to run the application; and        2. The Application Information Table (AIT).        
The OCAP Specification defines the service AIT. This table is broadcast for every service that contains an OCAP application, and it contains an entry for every application that is valid for that service. Thus, if a service has two applications associated with it, this table will contain two entries. The broadcast of the AIT “signals” the OCAP host device that applications exist. Other elements of the AIT allow the OCAP host device to determine whether the device is authorized to run the application.
FIG. 2 illustrates an AIT according to the OCAP 1.0 profile.
The AIT contains all the information that the OCAP host device needs to run the application and to tell the user of the OCAP host device what applications are available in a meaningful way. This includes elements such as the name of the application, the location of its files and any arguments that should be passed to the application when it starts.
The AIT contains table data 210 and two descriptor loops that describe the applications within the AIT. The common descriptor loop 220 contains descriptors that apply to all applications within the AIT, while the application descriptor loop 230 contains descriptors that apply to a particular application.
In practice, when a service change occurs, an application manager (not illustrated) in the host device examines the current set of applications. Any applications that are signaled as being service bound to the previous service are immediately terminated. The application manager examines every application that is signaled on the new service. Any applications that are signaled as auto-start are loaded and started. Any applications that were already running and are not signaled directly in the AIT are compared against the application identifiers (see FIG. 2, application descriptor loop 230) listed in the external application authorization descriptors. Any already running application that is not signaled in the AIT associated with the new service and is not listed in these descriptors is terminated.
FIG. 3 illustrates a typical OCAP environment 300. A head end device 301 supplies a data stream to a host device 305. In this illustration, the head-end device 301 creates an AIT 311 and transmits it to the host device 305. The host device 305 extracts application identifying information from the AIT 311. The host device issues a download request 303 to the head-end device 301 and downloads the identified applications from the head-end device 301.
In a typical OCAP environment, such as the one illustrated in FIG. 3, all applications are pushed to a set-top device regardless of whether the device requires the application to function. For example, if the AIT includes DVR related applications, the DVR applications will be pushed to all set-top devices regardless of whether they have DVR capabilities. As such, OCAP utilizes an “All or None” philosophy with the downloading of applications.
An OCAP host device can also run applications which are not bound to any service. In this case, information about those applications cannot be broadcast as part of a service, because the applications themselves are not part of a service. To solve this problem, OCAP defines an additional way of delivering information about applications the Extended Application Information Table (XAIT). The XAIT can be delivered to the OCAP host device in a number of ways known in the art. The XAIT contains information about unbound applications, such as the monitor application and the electronic program guide, in a manner similar to that used by the AIT.
A similar architecture is reflected in the Digital Video Broadcasting (DVB) standards and utilized by a DVB host device to perform the same functions as the OCAP host device. In the description that follows, the term “host device” encompasses both an OCAP host device and a DVB host device.
Currently, when a host device processes the AIT and the XAIT, it must load all signaled applications listed in the AIT or XAIT. There are many situations, however, in which it is desirable to run different bound and unbound applications on different hosts on the same network. An MSO might have different versions of an EPG application for DVR and non-DVR hosts. There might be discrepancies in the behavior of a particular type of host device that at least temporarily requires the MSO to run a different version of the application on that type of device. During upgrades, an MSO may want to test a new version of an application on a small number of host devices before deploying the new version to all customers. In a development environment multiple developers on the same network may want to run different applications. In all of these cases, it is desirable to signal a different set of applications to different host devices.
For example, a MSO has a single application that provides electronic program guide (EPG) and monitor functionality. A new version of this application has been tested and is ready to deploy. In order to minimize risk, each cable system within the MSO would benefit from a step wise deployment with the following phases:                (1) a few host devices in the headend;        (2) 10s of host devices that belong to friendly employees;        (3) 100s of host devices on a particular hub; and        (4) System wide deployment.        
As another example, a development lab has several developers working on the same application and each developer wants to run his or her own version of the application to test the changes that they are making.
As the examples discussed above illustrate, the present OCAP application downloading system is deficient in several ways. First, the downloading system wastes processor resources at user set-top devices. There are limited processing resources at each device, and downloading unnecessary applications wastes these resources. Likewise, pushing all applications to each set-top device inefficiently consumes valuable and limited storage at each device. Storing unnecessary applications on a device that will not be able to use them is therefore inefficient.
What is needed is a system and method of OCAP application downloading where the applications are targeting for each individual set-top device based upon parameters unique to the set-top devices themselves which define the needs/requirements/desires of the set-top devices